HLD link: sonic-net/SONiC#1522

- Why I did it
SONiC provides two Python logger implementations: sonic_py_common.logger.Logger and sonic_py_common.syslogger.SysLogger. Both of them do not provide the ability to change log level at real time. Sometimes, in order to get more debug information, developer has to manually change the log level in code on a running switch and restart the Python daemon. This is not convenient.

SONiC also provides a C/C++ logger implementation in sonic-platform-common.common.logger.cpp. This C/C++ logger implementation is also a wrapper of Linux standard syslog which is widely used by swss/syncd. It provides the ability to set log level on fly by starting a thread to listen to CONFIG DB LOGGER table change. SONiC infrastructure also provides the Python wrapper for sonic-platform-common.common.logger.cpp which is swsscommon.Logger. However, this logger implementation also has some drawbacks:

swsscommon.Logger assumes redis DB is ready to connect. This is a valid assumption for swss/syncd. But it is not good for a Python logger implementation because some Python script may be called before redis server starting.
swsscommon.Logger wraps Linux syslog which only support single log identifier for a daemon.
So, swsscommon.Logger is not an option too.

This PR is a Python logger enhancement which allows user setting log level at run time.

- How I did it
swsscommon.Logger depends on a thread to listen to CONFIG DB LOGGER table change. It refreshes log level for each logger instances once the thread detects a DB entry change. A thread is considered heavy in a python script, especially that there are many short and simple python scripts which also use logger. To keep python logger light weight, it uses a different design than swsscommon.Logger:

A class level logger registry shall be added to SysLoggerclass
Each logger instance shall register itself to logger register if enables runtime configuration
Logger configuration shall be refreshed by CLI which send a SIGHUP signal to the daemon

- How to verify it
Manual test
New unit test cases

HLD link: sonic-net/SONiC#1522

- Why I did it
SONiC provides two Python logger implementations: sonic_py_common.logger.Logger and sonic_py_common.syslogger.SysLogger. Both of them do not provide the ability to change log level at real time. Sometimes, in order to get more debug information, developer has to manually change the log level in code on a running switch and restart the Python daemon. This is not convenient.

SONiC also provides a C/C++ logger implementation in sonic-platform-common.common.logger.cpp. This C/C++ logger implementation is also a wrapper of Linux standard syslog which is widely used by swss/syncd. It provides the ability to set log level on fly by starting a thread to listen to CONFIG DB LOGGER table change. SONiC infrastructure also provides the Python wrapper for sonic-platform-common.common.logger.cpp which is swsscommon.Logger. However, this logger implementation also has some drawbacks:

swsscommon.Logger assumes redis DB is ready to connect. This is a valid assumption for swss/syncd. But it is not good for a Python logger implementation because some Python script may be called before redis server starting.
swsscommon.Logger wraps Linux syslog which only support single log identifier for a daemon.
So, swsscommon.Logger is not an option too.

This PR is a Python logger enhancement which allows user setting log level at run time.

- How I did it
swsscommon.Logger depends on a thread to listen to CONFIG DB LOGGER table change. It refreshes log level for each logger instances once the thread detects a DB entry change. A thread is considered heavy in a python script, especially that there are many short and simple python scripts which also use logger. To keep python logger light weight, it uses a different design than swsscommon.Logger:

A class level logger registry shall be added to SysLoggerclass
Each logger instance shall register itself to logger register if enables runtime configuration
Logger configuration shall be refreshed by CLI which send a SIGHUP signal to the daemon

- How to verify it
Manual test
New unit test cases

As of sonic-net#19611
and sonic-net/sonic-utilities#3428
a new database field of `require_manual_refresh` was added.

This leads to YANG failures in the factory-default configuration
for the `xcvrd` log entry which by default is written as true.

Signed-off-by: Brad House (@bradh352)

As of sonic-net#19611
and sonic-net/sonic-utilities#3428
a new database field of `require_manual_refresh` was added.

This leads to YANG failures in the factory-default configuration
for the `xcvrd` log entry which by default is written as true.

Signed-off-by: Brad House (@bradh352)

As of sonic-net#19611
and sonic-net/sonic-utilities#3428
a new database field of `require_manual_refresh` was added.

This leads to YANG failures in the factory-default configuration
for the `xcvrd` log entry which by default is written as true.

Signed-off-by: Brad House (@bradh352)

As of sonic-net#19611
and sonic-net/sonic-utilities#3428
a new database field of `require_manual_refresh` was added.

This leads to YANG failures in the factory-default configuration
for the `xcvrd` log entry which by default is written as true.

Signed-off-by: Brad House (@bradh352)

As of sonic-net#19611
and sonic-net/sonic-utilities#3428
a new database field of `require_manual_refresh` was added.

This leads to YANG failures in the factory-default configuration
for the `xcvrd` log entry which by default is written as true.

Signed-off-by: Brad House (@bradh352)

As of sonic-net#19611
and sonic-net/sonic-utilities#3428
a new database field of `require_manual_refresh` was added.

This leads to YANG failures in the factory-default configuration
for the `xcvrd` log entry which by default is written as true.

Signed-off-by: Brad House (@bradh352)

As of sonic-net#19611
and sonic-net/sonic-utilities#3428
a new database field of `require_manual_refresh` was added.

This leads to YANG failures in the factory-default configuration
for the `xcvrd` log entry which by default is written as true.

Signed-off-by: Brad House (@bradh352)

As of sonic-net#19611
and sonic-net/sonic-utilities#3428
a new database field of `require_manual_refresh` was added.

This leads to YANG failures in the factory-default configuration
for the `xcvrd` log entry which by default is written as true.

Signed-off-by: Brad House (@bradh352)

As of sonic-net#19611
and sonic-net/sonic-utilities#3428
a new database field of `require_manual_refresh` was added.

This leads to YANG failures in the factory-default configuration
for the `xcvrd` log entry which by default is written as true.

Signed-off-by: Brad House (@bradh352)

As of sonic-net#19611
and sonic-net/sonic-utilities#3428
a new database field of `require_manual_refresh` was added.

This leads to YANG failures in the factory-default configuration
for the `xcvrd` log entry which by default is written as true.

Signed-off-by: Brad House (@bradh352)

As of sonic-net#19611
and sonic-net/sonic-utilities#3428
a new database field of `require_manual_refresh` was added.

This leads to YANG failures in the factory-default configuration
for the `xcvrd` log entry which by default is written as true.

Signed-off-by: Brad House (@bradh352)

Why I did it
YANG failures during config replace with default configuration.

As of #19611 and sonic-net/sonic-utilities#3428 a new database field of require_manual_refresh was added.

This leads to YANG failures in the factory-default configuration for the xcvrd log entry which by default is written as true.

Work item tracking
How I did it
Updated YANG file for new field.

How to verify it
Verify config replace works with factory default configuration.